Release 10.1A: OpenEdge Development:
Progress 4GL Handbook

Dynamic programming considerations

Using a dynamic object lets you make everything about the data run-time defined, including the table name, the WHERE clause for the records you select, and so on. It’s important to note here some basic principles of dynamic programming that pertain specifically to transaction management.

The basic rule of dynamic programming is that, because you are defining a procedure’s behavior at run time, it is not possible for Progress to provide as much default behavior as it does for a statically defined procedure or to give you compile errors for constructs that are incorrect. You have much more responsibility to make sure that your program functions properly at run time with the entire range of possible data input that can drive its dynamic behavior. Because of this, there are a few basic rules you need to strictly adhere to when you’re doing dynamic programming. These rules apply to static programming as well, but they are more essential in a dynamic procedure. Partly, this is because a dynamic procedure provides less predictable default behavior and has more flexibility in what it might be expected to do at run time. Also, it is because you cannot use tools such as the LISTING file to confirm the record scope and transaction scope for your procedure, because Progress cannot determine them with certainty until run time.

Here are the rules:

It is essential that you explicitly define every transaction using the TRANSACTION keyword in a block header. Because dynamic programming is largely independent of the normal block structure of Progress, your transaction scope is likely to be very unpredictable (and possibly larger than you expect).
Make sure you do not find a record with an EXCLUSIVE-LOCK or otherwise reference any buffer outside your defined transaction in such a way that you force the transaction scope to be larger than you expected. For example, if you find a record, then start a transaction block with a DO TRANSACTION header, and then update that record, Progress forces the scope of the transaction at run time to be larger than the DO TRANSACTION block. The scope will likely encompass the entire procedure, and your procedure will hold records and locks longer than you want.
Always use the dynamic BUFFER-RELEASE method on each buffer handle to release the record when you are finished with it. Again, this is because the default release handling is block-oriented and dynamic procedures are not tied to blocks as firmly as static procedures are.
Use the dynamic BUFFER-COPY method to copy multiple fields from one buffer to another, rather than assigning values to fields individually. This is also true for a static buffer in that using an ASSIGN statement for more than a few fields in a buffer is more expensive than copying the entire buffer. It’s especially true for dynamic programming, however, because in a static program you can at least ASSIGN multiple fields in a single statement, whereas in dynamic programming you can only assign a single field at a time.
When you run one procedure from another in a dynamic program, be especially careful that you do not reference record buffers or other objects in such a way as to adversely affect your transaction scope. This mistake is very easy to make because you can reference an object that is defined anywhere in your application if you have access to its handle. This kind of access can drastically change transaction scope at run time in ways you cannot easily predict just by casually looking at the block structure of your procedures.
There is little reason to use SHARE-LOCKS in any case, but it is especially unwise to ever use a SHARE-LOCK in a dynamic procedure. The transition from SHARE-LOCK to EXCLUSIVE-LOCK and back is obscure in the best of cases and very much so in a dynamic procedure. Using SHARE-LOCKs can lead to locks being held much longer than you expect.

Once again, these are valuable guidelines for any procedure, but especially so for one that uses dynamic statements.

The next and final chapter provides more guidelines on how to best develop applications with the Progress 4GL.